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1.0  INTRODUCTION  AND  BACKGROUND 


As  much  as  70S  of  a  system's  life  cycle  costs  are  determined  by 
decisions  made  during  the  concept  exploration  phase  of  system  develop¬ 
ment  (see  U.S.  General  Accounting  Office,  1985).  A  significant  portion 
of  these  costs  are  associated  with  manpower,  personnel  and  training 
requirements.  Failure  to  consider  human  system  integration  (HSI)  issues 
in  the  early  phases  leads  to  significant  costs  downstream.  According  to 
Graine  (1988).  for  example,  the  combined  cost  of  people  and  associated 
training  requirements  contribute  close  to  60  percent  of  the  life  cycle 
costs  of  a  weapon  system.  The  realities  of  shrinking  Defense  budgets 
and  reduced  manpower  in  the  Services  demand  a  thorough  consideration  of 
HSI  at  the  very  early  stages  of  acquisition  and  throughout  the  process 
to  minimize  the  costs  and  time  required  to  proceed  from  Phase  II  onward. 

Recently  completed  Air  Force  and  Army  studies  have  identified  the 
Manpower.  Personnel,  Training,  and  Safety  (MPTS)  decision  points  in  the 
acquisition  process  (Potempa  and  Gentner,  1989.  and  Rossmeissel  et  al., 
1990).  The  challenges  are  to  integrate  useful  and  usable  HSI  planning 
tools  into  the  early  acquisition  process,  and  ensure  that  the  methods 
and  supporting  databases  are  compatible  with  design  and  analyses  proces¬ 
ses  already  in  place. 

Booher  (1990)  claims  that  much  research  and  development  work 
remains  to  be  done  before  people,  cost,  and  product  data  can  be  inte¬ 
grated  by  systems  engineers  as  smoothly  as  hardware  and  cost  data  are 
today.  The  research  of  this  Phase  I  SBIR  defines  the  requirements  for 
an  integrated  planning  tool,  which  takes  advantage  of  existing  human 
factors,  manpower,  personnel,  and  training  (HMPT)  methods  and  interfaces 
them  with  existing  design  procedures.  The  remainder  of  this  introduc¬ 
tion  defines  the  research  objective  in  more  detail,  presents  a  summary 
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of  the  weapon  system  acquisition  process  in  light  of  human  system  inte¬ 
gration!  decisions,  and  lays  out  the  remainder  of  the  report. 


1.1  RESEARCH  OBJECTIVE 

To  develop  human-system  components  for  emerging  weapon  systems  in  a 
cost-effective  manner,  players  in  the  early  acquisition  phases  must  be 
able  to  assess  and  evaluate  the  performance  and  life  cycle  costs  of  the 
human  component  of  the  system  just  as  they  do  for  more  readily  under¬ 
stood  system  components  such  as  the  avionics  or  power  plant. 

Specialized  software  which  structures  the  vast  quantities  of  design 
related  human  factors,  manpower,  personnel,  and  training  information 
should  play  an  increasingly  critical  role  in  mission  planning  and  sys¬ 
tems  design.  Yet  for  the  system  designer  these  methodologies  may  appear 
inadequate,  fragmented,  or  too  cumbersome  to  be  of  use  in  their  restric- 
tivly  short  design  timeframe.  An  analysis  of  these  user  information 
needs,  the  capabilities  of  current  approaches,  and  the  specific  require¬ 
ments  for  a  comprehensive  analytic  approach  is  needed  to  ensure  that 
designers  of  complex  human  systems  will  have  useful,  usable,  and  used 
automated  planning  tools  in  the  future. 

Organizations  in  Defense  and  civilian  communities  have  been  defin¬ 
ing  policy  and  promoting  methods  to  consider  the  human  impact.  The  Air 
Force's  IMPACTS  and  the  Army's  MANPRINT  directives  are  efforts  to  formal 
ize  the  process  and  provide  the  design  community  with  useful  tools. 


i  DoD  and  Service  specific  directives  have  outlined  requirements  and 
procedures  for  considering  the  human  factor  in  system  acquisition. 
Within  OoDI  5000.2  (Department  of  Defense.  1991b).  it  is  referred  to 
as  Human  Systems  Integration  (HSI).  Within  the  Air  Force,  it  is  the 
Integrated  Manpower,  Personnel,  and  Comprehensive  Training  and  Safety 
(IMPACTS)  Process.  The  Army's  Manpower  Personnel  Integration 
(MANPRINT)  program  is  analogous.  In  all  cases,  potential  human-system 
induced  high  drivers  in  six  areas --human  factors,  manpower,  personnel, 
training,  health  hazard,  and  system  safety-must  be  identified  and 
minimized  prior  to  passing  milestone  review.  For  this  report,  the 
concepts  (HSI,  IMPACTS,  and  MANPRINT)  are  interchangeable. 
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Unfortunately,  many  of  the  existing  tools  take  a  bottom-up  approach  to 
the  problem,  starting  with  detailed  task  descriptions  or  requiring  vast 
amounts  of  predecessor  system  data,  which  often  precludes  their  use 
prior  to  Milestone  I  at  the  end  of  Preconcept  Exploration. 

What  is  needed  is  an  accessible,  compatible  computer-aided  system 
which  starts  with  top-down  system  descriptions  for  functions,  informa¬ 
tion  . equi rements .  and  performance  characteri sti cs  in  increasing  levels 
of  detail,  and  supports  the  necessary  design  analyses.  The  system 
should  facilitate  function  analysis  and  dynamic  performance  analysis, 
and  produce  output  which  supports  the  various  reporting  requirements  for 
human  system  integration,  and  avoids  costly  decisions  later. 

The  research  objective  of  this  Phase  I  SB  I R  was  to  establish  the 
functional  requirements  for  an  effective  design  analysis  and  crew  per¬ 
formance  assessment  methodology  for  starting  during  concept  development 
and  feeding  subsequent  phases.  The  resulting  requirements  provide  direc¬ 
tion  for  developing  a  prototype  automated  system  in  Phase  II.  Function¬ 
al  and  information  requirements  of  existing  automated  tools  such  as  the 
Integrated  DEFinition  Language  (IDEF)  top-down  structured  analysis  meth¬ 
odology.  the  Systems  Analysis  of  Integrated  Networks  of  Tasks  (SAINT) 
simulation  model,  and  various  training  and  human  performance  models  were 
evaluated,  along  with  relevant  non-automated  approaches. 

Among  the  questions  answered  in  Phase  I  were: 

•  What  are  the  information  and  decision  requirements  for  human- 
system  integration  in  the  pre-Milestone  I  planning  process? 

•  What  planning  tools  are  currently  available?  How  do  they  meet 
the  user  needs? 

•  What  new  tools  are  needed? 

•  How  can  the  HSI  information  databases  be  structured  to  tie 
different  but  necessary  modeling  approaches  tonether? 

This  effort  relied  on  lessons  learned  during  the  development  of 
existing  methods,  and  discussions  with  potential  system  users  (e.g.. 
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training  developers)  to  determine  requirements  to  answer  critical  design 
decisions  in  a  timely  fashion.  The  system  recommendations  also  consider 
the  technology  requirements  and  constraints  of  actual  users.  System 
affordability  ( i .  e . .  cost  to  set  up,  train,  and  use)  and  accessibility 
are  key  concerns. 

1.2  DEFENSE  SYSTEMS  ACQUISITION  PROCESS 

The  principal  objective  of  the  defense  systems  acquisition  process 
is  to  acquire  and  deploy  effective  systems  in  response  to  an  identified 
deficiency  or  threat,  or  to  capitalize  on  technology  breakthrough,  and 
thereby  increase  total  force  effectiveness.  The  objectives  of  the  acqui¬ 
sition  management  decision  makers  are  to  influence  and  approve  a  cost- 
effective  system  acquisition  program  at  key  milestones,  and  to  provide 
the  information  necessary  to  program  and  budget  for  the  implementation 
of  the  system.  This  acquisition  process  is  designed  to  develop,  pro¬ 
cure.  and  field  a  totally  integrated  and  supportable  system  of  technol¬ 
ogy.  people  and  organizations,  and  to  ensure  that  the  complex  system 
meets  its  cost,  schedule,  and  performance  goals  (Rossmeissel  et  a  1 . . 
1990). 

The  primary  objective  of  DoD  programs  such  as  IMPACTS  and  MANPRINT 
is  to  influence  system  design  so  that  the  least-cost  system  makes  the 
best  use  of  the  human  resources  that  are  available.  Key  decision  makers 
must  understand  the  importance  of  human  issues  (Manpower,  Personnel, 

Human  Factors,  System  Safety.  Health  Hazard,  and  Training)  and  design 
engineers  must  be  willing  to  work  with  IMPACTS  or  MANPRINT  practitioners 
to  integrate  these  considerations  into  the  engineering  process.  These 
perspectives  must  be  considered  from  a  total  system  perspective,  and 
throughout  the  process,  as  shown  in  figure  1. 
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FIGURE  1 :  INTEGRATION  BETWEEN  HSI  ISSUES,  ANALYSIS  TOOLS,  AND 

DECISION  MAKING  CAPABILITY  AND  THE  ACQUISITION  PROCESS 


The  defense  system  acquisition  process  for  conceiving,  developing, 
acquiring,  and  fielding  new  systems  is  formalized  in  Department  of 
Defense  (DoD)  Directives  5000.1,  while  the  policies  and  procedures  are 
specified  in  DoDI  5000.2  (Department  of  Defense.  1991a. b).  The  primary 
phases  in  the  traditional,  full -development  acquisition  process  include 
Preconcept.  Concept  Exploration/Definition.  Concept  Demonstration  and 
Validation.  Full  Scale  Development,  and  Production  and  Initial  Deploy¬ 
ment.  Milestones  mark  the  transition  between  phases,  with  Milestone  I 
occurring  between  the  Concept  Exploration/Definition  and  Concept  Demon¬ 
stration/Validation  phases.  These  phases  are  described  in  figure  2. 
along  with  the  principal  HSI  objectives  in  each  phase.  Key  HSI  activi¬ 
ties  include  planning;  requirements  formulation;  solicitation  and  source 
selection;  and  design  and  validation. 

An  HSI  planning  tool  should  aid  in  identifying  HSI  issues  and  deci¬ 
sions  that  must  be  addressed  during  the  acquisition  of  the  system  and 
plan  for  activities  and  analyses  for  the  remainder  of  the  acquisition 
cycle.  The  tool  should  aid  system  planners  in  investigating  HSI  issues 
and  determine  whether: 

•  The  total  system  will  meet  performance  requirements. 

•  Available  manpower  will  be  sufficient  to  operate,  maintain, 
and  effectively  support  the  total  system. 

•  Personnel  will  have  the  skills  and  abilities  to  perform  the 
tasks  necessary  to  operate,  maintain,  and  support  the  system. 

•  Personnel  with  the  right  skills,  abilities,  and  training  will 
be  at  the  right  place  and  at  the  right  time  to  properly 
operate,  maintain,  and  support  the  system. 

•  Individuals  will  perform  the  required  tasks  correctly  under 
all  operational  and  environmental  conditions. 

•  Operation,  maintenance,  or  support  of  the  system  will  not 
result  in  safety  or  environmental  hazard  problems. 
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This  report  establishes  the  requirements  for  a  pre-Milestone  I  HMPT 
planning  tool.  TACHSI:  Tool  for  Analyzing  Concepts  in  Human  System  Inte¬ 
gration.  Section  1.0  lays  out  the  rationale  for  the  tool  in  the  context 
of  the  Defense  Systems  Acquisition  Process.  Section  2.0  describes  the 
research  methods  employed  during  the  Phase  I  SBIR.  Section  3.0  reviews 
current  automated  approaches  and  methods  which  were  considered  for  inclu¬ 
sion  in  the  system  requirements,  and  defines  evaluation  criteria  for  se¬ 
lecting  specific  methods.  Section  4.0  defines  specific  system  require¬ 
ments.  in  terms  of  process  diagrams,  and  user,  functional,  information 
and  technology  requirements.  Finally.  Section  5.0  presents  recommenda¬ 
tions  for  implementing  a  prototype  system  in  the  Phase  II  SBIR  effort. 

Key  prototype  components  are  highlighted. 


2.0  METHODS 


Several  sources  were  used  to  determine  requirements  for  the  HMPT 
planning  tool  TACHSI.  Air  Force  (AF)  and  DoD  publications  and  studies 
of  HMPT  issues  in  the  system  acquisition  process  were  reviewed  for  poten¬ 
tial  requirements,  complimentary  approaches,  and  sources  of  tools  to 
integrate.  After  analyzing  the  documentation  of  the  current  process, 
selected  user  groups  were  interviewed.  Results  of  these  interviews  were 
compared  against  the  documented  procedures.  Potential  data  sources  were 
also  investigated. 

2.1  REVIEW  OF  AVAILABLE  LITERATURE  AND  DOCUMENTS 

Integrating  HMPT  into  the  system  acquisition  process  is  not  a  new 
topic  of  study.  Recently  completed  studies,  including  some  performed 
for  the  Air  Force,  were  evaluated  for  insights  into  process  require¬ 
ments.  user  groups,  the  types  of  information  needed  to  support  the  pro¬ 
cess.  and  the  reporting  requirements.  Included  among  these  were  the  Hay 
Systems  study  of  MPTS  done  for  the  AF  Human  System  Division  (HSD/XR)  by 
Rossmeissel  et  al.  (1990);  the  development  of  an  IMPACTS  analysis  archi¬ 
tecture  for  concept  exploration  by  Allan  and  Johnson  (1991);  surveys  of 
human  factors  engineering  tools  applicable  to  MANPRINT  and  IMPACTS 
(Fleger  et  al..  1988;  Booher  and  Hewitt.  1990);  and  the  AF  IMPACTS 
Process  Handbook  (Flint  and  Johnson,  1991). 

The  HSO/XR  IDEF  study  of  MPTS  in  the  weapon  system  acquisition  pro¬ 
cess  described  the  issues  and  decision  points  that  should  be  addressed 
to  make  the  acquisition  system  more  responsive  to  MPTS  concerns.  Each 
phase  of  the  acquisition  process  was  described  in  a  top-down  format 
through  IDEFo  diagrams  and  supplementary  comments  and  explanations.  The 

acquisition  process  was  viewed  as  a  series  of  activities  and  the  MPTS 
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related  issues  and  decisions  were  linked  to  specific  acquisition  activi¬ 
ties.  Figures  3  and  4  show  the  two  top-level  IDEF0  process  diagrams 

resulting  from  this  study1. 

The  study  by  Allen  and  Johnson  (1991)  focused  on  MPTS  assessment 
within  concept  exploration,  and  developed  an  analytic  architecture  for 
determining  the  human-centered  concerns  associated  with  conceptual  de¬ 
signs  during  defense  system  acquisition.  It  defined  a  series  of  analy¬ 
tic  steps,  where  each  step  was  characterized  by  its  inputs,  transac¬ 
tions.  and  outputs,  and  generated  IMPACTS  decision  data  required  for 
Milestone  I.  The  architecture  served  as  the  foundation  for  a  more  de¬ 
tailed  investigation  in  the  future.  It  differs  from  the  Hay  study  in 
focus  and  depth,  focusing  solely  on  pre-Milestone  I  issues. 

One  of  the  most  complete  surveys  of  human  factors  tools  applicable 
to  the  system  acquisition  stages  was  performed  for  the  Army  in  1988 
(Fleger  et  a  1 . ) .  The  study  identified  113  advanced  tools  in  human  fac¬ 
tors  engineering  alone,  but  only  15  were  shown  to  be  operational  and 
applicable  to  concept  exploration  phases  in  MANPRINT  analyses.  Several 
of  the  operational  human  factors  evaluation  ( HFE )  task  models  were 
considered  in  section  3.0  of  this  report. 

A  broader  set  of  IMPACTS/MANPRINT  tools  and  techniques  were  eval¬ 
uated  in  Booher  and  Hewitt  (1990).  This  analysis  included  the  best  of 
the  HFE  tools  identified  by  Fleger  et  a  1 . .  as  well  as  the  best  of  the 
MPT  tools  identified  in  a  variety  of  Service-specific  studies.  Tools 
and  techniques  were  summarized  and  classified  by  system  acquisition 


1  IDEFo  is  a  diagramming  methodology  showing  component  parts. 

interrelationships  among  them,  and  how  they  fit  into  a  hierarchical 
structure.  IOEFo  diagrams,  which  progress  from  the  general  to  the 
more  specific,  are  composed  of  boxes  representing  processes,  arrows 
denoting  data  or  objects,  and  labels  which  name  the  functions,  data 
and  objects.  Input  data  flows  into  the  process  from  the  left; 
output  leaves  from  the  right.  Control  data  enters  the  process  from 
above,  and  mechanism  objects  are  linked  from  beneath. 
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FIGURE  3:  TOP-LEVEL  IDEF  PROCESS  DIAGRAM  FOR  STUDY  OF  MPTS  IN  THE 

WEAPON  SYSTEM  ACQUISITION  PROCESS  (from  Rossmeissel  et  al.,  1990) 
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FIGURE  4:  PRIMARY  ACTIVITIES  (PHASES)  IN  WEAPON  SYSTEM  ACQUISITION 
PROCESS  WITH  MAJOR  INPUTS,  OUTPUTS,  CONSTRAINTS,  AND 
MECHANISMS  (from  Rossmeissel  etal.,  1990) 


phase.  HSI  domain,  type  of  activity,  analytical  technique  (task  or  com¬ 
parability,  simulation  or  statistical),  theoretical  basis  (empirical  or 
analytical),  and  availability. 

The  IMPACTS  Process  Handbook  reflects  the  need  for  'how  to*  guid¬ 
ance  on  initiating  the  IMPACTS  program  and  satisfying  DoD  requirements 
for  front-end  consideration  of  the  human  as  an  integral  element  of  the 
system.  It  concentrates  on  a  practical  step-by-step  approach,  focused 
at  the  Air  Force  MAJor  COMmand  (MAJCOM)  for  identifying  system-related 
human  issues  for  initiation  of  a  Preliminary  IMPACTS  Program  Plan  (PIPP) 
and  subsequent  integration  of  human  issues  into  the  Mission  Need  State- 
Oment  (MNS)  (Flint  and  Johnson.  1991).  The  handbook  provides  a  detailed 
approach  for  early  analysis  to  support  identification  of  IMPACTS-related 
issues  prior  to  Milestone  I.  It  identified  17  databases  as  important 
resources  for  supporting  IMPACTS  analysis,  and  included  brief  descrip¬ 
tions  of  these  databases. 

2.2  INTERVIEWS  WITH  USER  GROUPS  AND  DATA  SOURCES 

While  the  need  to  consider  HMPT  factors  in  the  early  stages  of  sys¬ 
tem  acquisition  has  been  stated  for  years,  it  has  not  yet  become  real¬ 
ity.  Therefore,  we  interviewed  potential  users  in  the  Training  Special 
Program  Offices  (SPO).  and  members  of  the  Logistics  Directorate  ( XRL) . 
at  Wright-Patterson  AFB,  Ohio.  The  interviews  determined  the  means  by 
which  users  currently  interface  with  the  acquisition  process,  the  type 
of  information  they  use,  data  sources,  time  constraints,  and  any  special 
procedures  which  should  be  considered  in  designing  a  planning  tool. 

These  results  were  used  to  create  a  preliminary  profile  of  user 
requirements  in  terms  of  functions,  inputs,  outputs,  and  constraints. 

The  types  of  information  available  and  desired,  useful  system  functions, 
and  workstation  platform  restrictions,  were  identified.  Additional  data 
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on  the  time-criticality  of  information  and  the  sequence  of  decisions  in 
the  planning  process  were  determined.  For  Phase  I.  the  scope  of  users 
was  limited  to  those  available  at  ASD  at  WPAFB.  This  was  justified 
given  the  limited  scope  of  players  in  the  Pre-Milestone  I  planning 
process . 

In  addition  to  potential  users,  potential  data  sources  such  as  the 
Crew  Systems  Ergonomics  Information  Analysis  Center  (CSERIAC)  were 
investigated.  CSERIAC's  objective  is  to  support  DoD  requirements  for 
incorporating  crew  system  ergonomics  into  the  design  and  operation  of 
military  systems.  Its  mission  is  to  provide  ergonomic  information  analy 
sis  services  to  support  research,  design,  and  development  of  space,  air. 
surface,  and  subsurface  crew  systems.  Data  from  the  Engineering  Data 
Compendium  (Boff  and  Lincoln.  1988).  soon  to  be  available  electronical ly 
on  laser  disc,  would  be  a  source  of  human  performance  data  to  populate 
performance  databases  which  support  simulation  models.  The  Compendium 
consolidated  scattered  research  findings  in  a  format  intended  to  make  it 
easier  to  interpret  and  apply.  Data  were  considered  for  selection  based 
on  reliability,  representativeness,  generalizability.  and  relevance. 

The  planning  tool  should  be  applicable  to  later  phases  in  the  acqui 
sition  decision  process,  and  contain  compatible  information  wherever  pos 
sible.  These  interfaces  were  discussed  with  members  of  the  Acquisition 
Logistics  (ALH)  community. 

2.3  DEVELQPIHfi  SYSTEM  REQUIiEMEHIS 

User  interview  results  were  used  to  produce  a  set  of  requirements 
defining  the  functions,  information,  and  host  platform  needed  in  the 
resulting  methodology.  These  were  used  as  a  benchmark  for  defining 
system  requirements  for  a  planning  system  which  will  be: 


14 


•  useful . 

•  usable,  and 

•  used. 

Rather  than  build  one  more  tool,  the  task  of  this  research  is  to  develop 
a  structure  for  integrating  existing  tools  which  apply  to  the  concept 
exploration  phase  of  system  acquisition. 

Factors  describing  the  user  community,  procedures,  physical  environ¬ 
ment.  and  system  integration  issues  were  analyzed.  The  resulting  plan¬ 
ning  system  will  function  in  the  context  of  other  planning  activities 
within  complex  design  activities.  The  proposed  system  requirements,  de¬ 
scribed  in  section  4.0,  are  driven  by  principal  information  needs,  but 
still  consider  the  complete  system  context  and  existing  tools,  existing 
system  interfaces,  planned  systems  which  will  interface  with  the  pro¬ 
posed  system,  departmental  standards  for  interoperability.  DoD  policies 
and  directives,  and  existing  computer  systems  which  support  the  project. 
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3.0  REVIEW  OF  CURRENT  MPT  APPROACHES 


A  wide  range  of  automated  HMPT  methods  and  approaches  exist  or  are 
in  various  stages  of  development.  Comparative  studies,  conference  pro¬ 
ceedings.  and  process  handbooks  are  full  of  descriptions.  This  section 
reviews  current  HMPT  approaches  with  potential  relevance  to  this  phase 
of  system  acquisition,  and  identifies  those  for  subsequent  inclusion  in 
the  prototype  planning  tool. 

Section  3.1  provides  an  overview  of  five  classes  of  MPTS  tools  con¬ 
sidered  in  this  study:  section  3.2  reviews  candidate  models  considered 
in  each  class.  Section  3.3  includes  a  discussion  of  tool  selection  cri¬ 
teria.  based  in  part  on  criteria  developed  and  applied  to  a  Front  End 
Analysis  of  an  integrated  Manpower.  Personnel,  and  Training  Analysis  Sys¬ 
tem  (MPTAS)  (Kerchner.  1991)  and  of  those  used  in  a  decision  table  for 
MANPRINT  tool  selection  (Boohcr  and  Hewitt.  1990).  The  Models  described 
in  section  3.2  are  evaluated  with  respect  to  these  criteria.  Section 
3.4  concludes  with  a  demonstration  of  the  TACHSI  concept  through  an 
application  of  the  Integrated  Design  and  Engineering  Analysis  Language 
( I OEAt )  methodology . 

3.1  SCOPE  OF.  mi  TOOLS 

Several  classes  of  MPTS  tools  were  candidates  for  inclusion  in  the 
TACHSI  planning  tool.  These  included: 

•  integrated  design/analysis  methodologies  (e.g.,  IDEAL); 

•  top-down  process  decomposition  and  system  description  methods 
(e.g..  IDEFo); 

•  bottom-up  task  analysis/operator  simulation  methods  (e.g.. 
SAINT,  MicroSAINT,  Simulation  Language  for  Alternative 
Modeling  (SLAM)); 

•  design-criented  human  performance  assessment  (e.g.,  MIDAS. 

IDEAL  Performance  Database.  Isoperformance):  and 
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•  training/Instructional  System  Development  (ISD)  requirements 
and  cost  estimation  aids  (e.g.,  ISD-LSAR  DSS.  and  MIDAS-TAM). 

The  top-down  process  description  method  is  missing  from  most  HSI 
methods  and  approaches,  yet  it  is  an  approach  that  is  central  to  the 
system  design  community.  This  structured  decomposition  of  processes, 
functions,  or  activities  was  formalized  for  the  Air  Force  through  the 
Structured  Analysis  and  Design  Technique  (SADT),  and  later  presented  as 
the  IDEF  methodology  (SofTech.  1981).  It  has  been  used  by  the  AF  to 
describe  the  MPTS  issues  in  the  acquisition  process  (Rossmeissel  et  al., 
1990).  but  has  not  yet  been  included  in  any  description  of  MPTS  tools. 
Including  this  in  the  TACHSI  planning  tool  will  permit  greater  communi¬ 
cation  with  the  engineering  community,  and  will  enhance  ease  of  use  in 
the  early  acquisition  phases. 

The  goal  in  this  analysis  is  to  scan  across  a  range  of  classes  of 
models,  and  select  those  with  the  best  potential  for  complementing  the 
combined  functionality  of  the  planning  tool.  An  exhaustive  search  of 
all  models  is  not  included  for  several  reasons: 

•  In  many  cases,  it  has  been  done  before  in  both  IMPACTS  and 
MANPRINT  domains,  for  human  factors  engineering  and  MPT 
analysis  tools. 

.  In  the  interest  of  time,  in-house  expertise  with  models  and 
analyses  can  be  more  effective  than  exhaustive  searches  to 
point  out  what  does  and  does  not  work. 

The  TACHSI  design  leverages  off  of  existing  methodologies,  simula¬ 
tion  tools,  and  graphical  human  factors  design  systems  in  use  or  under 
development  in  the  DoD  community.  As  mentioned  previously,  examples 
exist  for  many  of  the  components  of  this  design  system.  The  goal  of  the 
Phase  I  research  is  to  identify  those  which  have  the  greatest  chance  for 
successful  integration,  and  to  enhance  the  planning  process. 
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Model  candidates  within  each  of  the  classes  are  presented  below. 


3.2.1  INTEGRATED  DESIGN/ANALYSIS  METHODOLOGIES 

The  current  IDEAL  modeling  methodology  is  a  proven  general-purpose 
methodology  for  modeling  a  wide  variety  of  system  types  (see  Evers  and 
Bachert.  1987).  IDEAL’S  power  lies  in  its  capability  to  utilize  knowl¬ 
edge-engineering  techniques  to  collect,  integrate,  and  verify  system 
information  from  a  team  of  people.  It  provides  the  capabilities  to 
build  a  system  simulation  in  a  top-down,  structured  manner,  in  a  nota¬ 
tion  that  communicates  and  documents  the  system,  and  in  a  form  execut¬ 
able  on  a  computer.  At  this  point  it  exists  as  a  penci 1 -and-paper  tool 
that  relies  on  automated  systems  for  the  top-down  hierarchical  system 
definition  and  in-depth  network  simulation  of  system  performance.  These 
automated  systems  reside  on  personal  computers  and  mainframes.  The 
steps  to  transition  between  the  functional  system  description  and  simula¬ 
tion  are  done  manually,  but  lend  themselves  to  automation  with  proper 
database  methods.  The  performance  database  (PDB)  is  t;ie  key  to  the 
IDEAL  concept,  and  is  described  in  section  3.2.4. 

Section  3.4  contains  a  sample  application  of  IDEAL  to  the  analysis 
of  cockpit  automation  concepts  and  human-performance  tradeoffs.  This 
example  will  help  to  clarify  how  TACHSI  could  be  applied  to  concept 
design. 

3.2.2  TOP-DOWN  PROCESS  DECOMPOSITION 

The  IDEF  technique  is  a  tool  for  building  descriptive  models  of 
system  functions  and  data  (SofTech,  1981).  An  activity  modeling  techni¬ 
que.  it  is  a  top-down  hierarchical  approach  used  to  graphically  illu¬ 
strate  system  functions.  IDEFq  uses  a  top-down  approach  to  produce  a 
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static  representation  of  a  system.  This  representation  is  in  the  form 
of  an  integrated  set  of  diagrams  consisting  of  boxes  (defining  system 
activities)  and  arrows  (defining  interfaces  among  the  activities).  The 
IDEFo  model  provides  a  graphic  definition  of  the  system  structure  in  a 

top-down,  gradual,  controlled  manner.  Through  an  IDEF0  model,  a  signifi¬ 
cant  amount  of  analysis  can  be  performed  with  regard  to  the  static  as¬ 
pects  of  the  system.  A  three-level  IDEFo  decomposition  is  shown  in  fig¬ 
ure  5.  The  principal  goal  of  IDEFo  is  to  provide  a  structured  approach 

for  breaking  a  complex  system  into  more  elemental  components  for  easier 
understanding.  IDEFo  has  been  used  to  model  man-machine  systems,  the 

ISD  process  (Haines  and  Evers.  1990).  automated  message  processing  sys¬ 
tems.  database  design,  manufacturing  capabilities,  and  software  design. 
Automated  IDEFo  systems,  such  as  Design/IDEF  by  Meta  Software,  exist  on 

personal  computers,  and  are  strong  candidates  for  inclusion  in  TACHSI. 
From  the  standpoint  of  human  performance  or  MPT  issues,  however,  IDEF 
falls  short  of  representing  task  dependencies,  temporal  issues,  and 
dynamic  modeling  or  performance  assessment. 

3.2.3  TASK  ANALYSIS/OPERATOR  SIMULATION  METHODS 

To  analyze  the  dynamic  or  operational  aspects  of  the  system,  one 
must  transform  the  IDEFo  model  into  a  dynamic  model  or  simulation.  This 

transformation  must  be  accomplished  in  the  most  efficient  way  possible 
in  order  to: 

•  minimize  the  simulation  development  time; 

•  minimize  the  validation  time; 

•  prevent  a  user  from  having  to  know  two  languages  (ie..  the 
IDEFo  language  and  the  simulation  language):  and 

•  provide  a  tight  correlation  between  the  models  so  that  change 
in  one  model  can  be  quickly  reflected  in  the  other  model. 
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FIGURE  5:  THREE-LEVEL  IDEFO  PROCESS  DECOMPOSITION 
(from  SofTech,  1986) 
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Of  the  many  simulation  languages  in  existence,  only  three  languages 
are  candidates  for  integrating  with  the  IDEF0  notation.  These  languages 

are  SAINT,  Micro-SAINT.  and  SLAM.  Each  of  these  languages  has  been  com¬ 
pared  to  the  IDEF0  technique  from  three  perspectives:  notation,  input. 

and  output. 

As  a  point  of  reference.  SAINT,  Micro-SAINT.  and  SLAM  are  closely 
related,  in  the  sense  that  Micro-SAINT  was  developed  based  on  the  same 
concept  as  SAINT,  but  with  reduced  capabilities.  SLAM  contains  much  of 
the  original  SAINT  code,  but  its  concept  has  been  directed  primarily 
toward  modeling  manufacturing  systems.  Therefore,  the  system  perspec¬ 
tive  presented  to  the  user  by  SLAM  is  more  oriented  toward  queue  analy¬ 
sis  rather  than  activity  and  information  flow  analysis. 

SAINT 

SAINT  is  a  network  modeling  and  simulation  technique  designed  to 
assist  in  the  design  and  analysis  of  complex  systems  (Seiffert  and 
Chubb.  1978).  SAINT  provides  the  conceptual  framework  for  representing 
systems  that  consist  of  discrete  task  elements,  continuous  state  vari¬ 
ables.  and  interactions  between  them.  An  upgraded,  customized  version 
of  SAINT,  identified  as  C-SAINT,  has  also  been  developed.  The  two  lan¬ 
guages  are  identical  in  concept,  but  a  few  modifications  have  been  made 
to  C-SAINT  to  decrease  the  effort  required  to  develop  a  simulation  and 
to  be  able  to  monitor  specific  performance  characteristics  of  a  system. 
Within  this  discussion.  SAINT  will  be  used  to  refer  to  both  SAINT  and 
C-SAINT.  Language  implementations  exist  for  IBM  and  VAX  mainframes,  as 
well  as  personal -computer  platforms. 

The  network  language  notation  of  SAINT  is  based  on  a  set  of  activ¬ 
ities  or  nodes  which  are  linked  together  to  represent  the  flow  of  infor¬ 
mation  or  objects  among  the  activities.  Each  activity  is  identified  by 
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a  name  and  is  characterized  by  a  number  of  factors.  These  factors 
include  items  such  as  task  performance  time,  task  processing,  defini¬ 
tion.  resources  requirements,  and  branching-sequence  definitions. 

Figure  6  shows  a  three-level  SAINT  activity  decomposition. 

The  SAINT  notation  is  fairly  simplistic  and  very  well  suited  for 
integration  with  the  IDEFo  notation.  The  primary  benefits  are:  there 

is  a  one-to-one  correlation  between  the  IDEFo  activities  and  the  SAINT 
nodes:  the  mechanisms  identified  in  the  IDEFo  model  correlate  directly 

to  the  resources  in  the  SAINT  network;  and  the  interfaces  among  the 
IDEFo  nodes  are  also  represented  in  the  SAINT  network.  The  correlation 

allows  for  a  very  close  visual  correspondence  between  the  two  notations; 
and  the  additional  dynamic  information  that  is  needed  to  generate  the 
dynamic  model  can  be  overlaid  onto  the  IDEFo  notation  without  requiring 

a  complex  translation  and  interpretation  process. 

SAINT'S  interface  is  based  on  the  old  80-column  card  format.  Each 
record  contains  a  well-defined  set  of  information  fields,  with  the 
fields  separated  by  commas.  This  interface  causes  problems  for  those 
not  familiar  with  SAINT,  but  is  very  effective  for  those  who  are  profi¬ 
cient  because  there  are  no  restrictions  regarding  the  order  in  which 
records  have  to  be  developed  or  stored.  Therefore,  the  SAINT  interface 
provides  an  effective  format  around  which  an  automated  IDEFo*to-SAINT 

translation  program  can  be  built. 

The  basic  output  of  SAINT  is  minimal  and  is  in  table  form  showing 
resource  utilization.  With  some  minimal  additional  programming,  the 
amount  of  output  information  can  be  increased  significantly  or  be  easily 
read  into  other  application  programs,  such  as  a  spreadsheet,  which  could 
provide  a  wide  range  of  graphing  and  analysis  capabilities. 
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FIGURE  6:  THREE-LEVEL  SAINT  ACTIVITY  NODE  DECOMPOSITION 
(from  SofTech,  1986) 
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Micro-SAINT 

Micro-SAINT  was  developed  as  a  reduced  version  of  SAINT  for  the  IBM 
PC.  The  basic  concepts  of  Micro-SAINT  remain  consistent  with  SAINT  in 
terms  of  representing  activities  and  information  flow.  Therefore,  the 
notation  correlation  between  Micro-SAINT  and  IDEFo  is  high. 

The  interface  for  Micro-SAINT  has  been  modified  from  the  80-column 
format  to  a  multilevel  set  of  interactive  prompting  menus.  This  inter¬ 
face  works  fine  for  a  novice  modeler,  but  becomes  a  hindrance  to  the 
experienced  modeler.  More  importantly,  this  menu  interface  becomes  a 
significant  problem  in  terms  of  developing  an  automated  transition  from 
IDEFo  to  Micro-SAINT.  Not  only  will  the  translation  program  have  to 

transfer  information,  it  will  also  have  to  control  the  manipulation  of 
the  menus. 

Originally,  the  output  of  Micro-SAINT  was  very  similar  to  that  of 
SAINT.  However,  the  main  output  has  been  modified  in  terms  of  present¬ 
ing  the  results  using  an  animation  concept.  Some  of  the  original  tables 
still  remain  and  could  be  read  into  other  application  programs  for  graph¬ 
ical  information  presentation. 

SLAM 

SLAM  was  developed  as  a  follow-on  to  SAINT.  SLAM  contains  some  of 
the  original  SAINT  code  and  retains  some  of  the  basic  concepts  of  SAINT. 
However,  the  goals  of  SLAM  were  redirected  toward  that  of  the  manufac¬ 
turing  environment.  Within  this  environment,  the  emphasis  is  placed 
almost  entirely  on  queue  build-ups  rather  than  task  performance  and 
information  flow.  As  a  result  of  the  change  in  emphasis,  the  notation 
of  SLAM  was  modified  from  the  SAINT  notation.  SLAM's  notation  signifi¬ 
cantly  reduces,  if  not  eliminates,  any  reasonable  correlation  between 
IDEFq  and  SLAM. 
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SLAM  retained  most  of  the  original  80-column-card  input  format,  but 
also  has  a  multilevel  menu  interface  between  the  user  and  the  fixed 
input  format.  This  menu-driven  interface  has  been  well  thought  out  and 
designed  with  respect  to  developing  a  SLAM  model.  However,  when  auto¬ 
mating  the  transformation  from  I DE F0  to  SLAM,  this  menu  interface  will 

be  a  hindrance.  A  possible  approach  would  be  to  remove  the  menu  inter¬ 
face  and  go  back  to  the  80-column  format. 

The  primary  outputs  of  SLAM  are  a  couple  of  tables  and  an  optional 
animated  presentation  of  the  output.  Some  additional  tables  can  be  gen¬ 
erated  through  the  development  of  user-specified  code.  The  tables  are 
formatted  so  that  they  can  be  transferred  into  other  programs,  such  as  a 
spreadsheet,  which  could  provide  graphic  representation  of  the  results. 

Summary 

To  provide  an  effective  linkage  between  IDEFo  and  a  simulation,  the 

two  languages  must  be  similar  in  concept  and  format.  The  brief  discus¬ 
sion  of  the  features  of  SAINT.  Micro-SAINT,  and  SLAM  have  been  summa¬ 
rized  in  figure  7.  Within  this  table,  "high*  indicates  that  there  is  a 
high  correlation  between  the  IDEFo  features  and  the  simulation  language 

features:  "low"  indicates  no  real  correlation. 


Concept/ 

Notation 

Input 

Output 

SAINT 

High 

High 

Medium 

Micro-SAINT 

High 

Low 

Medium 

SLAM 

Low 

Low 

Medium 

FIGURE  7:  RATING  OF  THE  CORRELATION  BETWEEN  IDEFo 
AND  SIMULATION  LANGUAGES 
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Because  the  three  simulation  languages  are  all  variants  of  SAINT, 
the  consistent  rating  of  “medium*  for  the  output  is  a  reasonable  expecta¬ 
tion.  The  "lows"  for  input  to  Micrc-SAINT  and  SLAM  are  due  to  their 
multilevel  menus  that  will  cause  difficulty  in  generating  an  automated 
interface  from  IOEFo  to  the  simulation.  The  ‘high*  for  SAINT’S  input  is 

due  to  the  procedural  flexibility  afforded  through  the  80-column  format. 
The  "low"  for  SLAM's  concept/notation  is  caused  by  the  switch  from  the 
task/information  flow  concept  to  a  queue  representation  concept  which 
does  not  align  with  the  IDEF0  activities.  The  "highs"  for  the  SAINT  and 

Micro-SAINT  inputs  are  due  to  the  fact  that  there  is  a  one-to-one 
correlation  between  the  IDEFq  activity  and  the  nodes  within  the 

simulation  languages. 

From  this  brief  comparison,  considering  that  the  concept/notation 
and  the  input  are  much  more  critical  aspects  for  the  transformation  than 
the  output,  SAINT  stands  out  as  the  only  language  that  can  be  reasonably 
pursued  with  respect  to  forming  an  effective  translation  from  IDEFo  to  a 

dynamic  simulation  capability.  To  further  strengthen  the  decision  for 
SAINT,  both  Micro-SAINT  and  SLAM  are  proprietary  packages  which  must  be 
licensed,  while  SAINT  is  owned  by  the  Air  Force  and  is  therefore  in  the 
public  domain. 

3.2.4  DESIGN-ORIENTED  HUMAN  PERFORMANCE  ASSESSMENT 

Three  alternative  approaches  are  discussed  for  human  performance 
assessment.  All  are  exploratory  systems,  with  the  Army-NASA  Aircrew/ 
Aircraft  Integration  ( A3 1 )  program  which  is  under  development  at  NASA- 
Ames.  The  Isoperformance  methodology  was  implemented  for  the  Air  Force 
as  a  prototype  package  as  part  of  a  Phase  II  SBIR  effort.  The  Perform- 
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ance  Database  exists  in  concept  form  as  a  repository  of  data  to  support 
the  IDEAL/IDEF/SAINT  methodology.  These  are  representative  of  the  types 
of  approaches  possible  for  inclusion. 

MIDAS 

The  A3 1  Program  is  a  joint  exploratory  development  effort  to 
advance  the  capabilities  and  use  of  computational  representations  of 
human  performance  and  behavior  in  the  design,  synthesis,  and  analysis  of 
manned  systems  (Smith.  1990).  The  program's  goal  is  to  conduct  and  inte 
grate  the  applied  research  necessary  to  develop  an  engineering  environ¬ 
ment  containing  the  tools  and  models  needed  to  assist  crewstation  devel¬ 
opers  in  the  conceptual  design  phase.  A  major  product  of  this  goal  is 
the  development  of  a  prototype  Human  Factors/Computer  Aided  Engineering 
system  called  MIDAS  (Man-Machine  Integration  Design  and  Analysis  Sys¬ 
tem).  This  system  provides  design  engineers/analysts  with  interactive 
symbolic,  analytic,  and  graphical  components  which  permit  the  early  inte 
gration  and  visualization  of  human  engineering  principles.  The  MIDAS 
system  is  currently  hosted  on  a  number  of  networked  Symbolics  and  Sili¬ 
con  Graphics  workstations.  This  configuration  provides  the  developers 
with  considerable  processing  power  and  flexibility,  but  produces  a  sys¬ 
tem  which  is  beyond  the  practical  financial  reach  of  many  potential  sys¬ 
tem  users. 

ISOPERFORMANCE 

The  Isoperformance  methodology  developed  by  Kennedy  et  al .  (1989), 
allows  the  systems  developer  to  fix  systems  effectiveness  criteria  and 
minimize  the  costs  of  MPTS  and  equipment  through  tradeoffs  among  cost 
factors.  Isoperformance  analyses  are  intended  to  be  implemented  as 
expert  systems  to  aid  in  decision  making  through  interactive  computer 
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programs  for  use  by  system  designers.  The  user  has  access  to  a  library 
of  relevant  information  and  system  output  consisting  of  a  family  of 
isoperformance  curves.  These  curves  are  used  to  make  comparisons  among 
various  local  components  relevant  to  systems  development  as  they  pro¬ 
gress  through  the  life  cycle.  A  prototype  implementation  of  the  method¬ 
ology  was  developed  as  a  decision  aid  in  specifying  factors  pertaining 
to  training  system  design.  Provided  with  the  proper  data.  Isoperform¬ 
ance  can  provide  program  managers  with  a  way  to  make  resource  allocation 
decisions . 

PERFORMANCE  DATABASE 

The  Performance  Database  (PDB)  is  a  concept  for  storing  necessary 
performance  data  to  drive  dynamic  simulation  models  (e.g.,  SAINT)  from 
limited  static  process  decomposition  models  (e.g..  IDEF0).  The  PDB  is 

populated  via  a  separate  interface,  and  contains  five  major  categories 
of  information.  Each  category  may  contain  parameters  for  continuous  and 
discrete  models.  Categories  include  Global  System  Characteristics,  Sce¬ 
nario  Specific  State  Conditions.  Resource  Attributes,  Function  or  Task 
Characteristics,  and  Environmental  Factors.  The  PDB  concept  differs 
from  MIDAS  or  Isoperformance  approaches  in  that  it  is  not  an  analysis  in 
itself,  but  a  structure  for  storing  information  to  support  other  analy¬ 
ses.  Values  for  resource  attributes,  task  characteristics,  or  environ¬ 
mental  factors  could  as  easily  support  training  analyses  as  network 
simulations.  Populating  the  database  can  be  time  consuming.  Object- 
oriented  techniques  for  specifying  generic  attributes  and  passing  values 
to  objects  of  similar  classes  should  be  investigated  during  implementa¬ 
tion  in  Phase  II  to  leverage  off  of  previous  designs  and  reduce  set-up 
time. 
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3.2.5  TRAINING/ISO  REQUIREMENTS 
ISD/LSAR  OSS 

Instructional  Systems  Development  (ISO)  is  a  systems  engineering 
approach  to  training  that  uses  an  iterative,  building-block  approach  to 
determine  the  training  system  design  requirements  of  a  given  weapon  sys¬ 
tem.  Specifically.  ISO  considers  the  relative  need  and  appropriate  meth¬ 
ods  to  train  each  weapon  system  task  and  task  element,  and  assesses  the 
skills  and  knowledge  of  a  target  student  population. 

The  Joint  Service  Instructional  System  Development/Logistics  Sup¬ 
port  Analysis  Record  ( LSAR)  Decision  Support  System  (DSS)  provides  an 
automated  link  for  LSAR  data  to  feed  the  ISD  process  as  the  LSAR  pro¬ 
ceeds  during  a  weapon  system  acquisition  (Dynamics  Research  Corporation. 
1991).  The  automated  ISD-to-LSAR  data  interface  is  a  powerful  technique 
that  effectively  integrates  concurrent  LSA  and  ISD  analysis  efforts. 

The  automated  link  to  LSAR  data  allows  ISD  analysts  more  time  to  effec¬ 
tively  evaluate  a  weapon  system's  training  requirements.  The  OSS  pro¬ 
vides  easy  access  to  current  LSAR  data,  which  enables  training  devices 
and  materials  to  more  accurately  reflect  dynamic  weapon  system  designs. 
Also,  automated  ISD  procedures  eliminate  labor-intensive  data  handling 
tasks  and  allow  training  analysts  to  effectively  analyze  training  system 
requi rements . 

The  ISD/LSAR  DSS  consists  of  LSAR  data  input  routines.  ISD  analysis 
processes,  and  modified  training  design  procedures  that  reflect  and  ac¬ 
commodate  service-specific  ISD  procedures.  The  system  includes  utility 
functions  that  provide  system  security,  database  administration,  report 
generation,  and  ISD  analysis  functions.  All  ISD  analyses  are  documented 
on  automated  worksheets.  Decision-support  logic  aids  the  user  in  select¬ 
ing  tasks  that  require  training,  selecting  instructional  settings  and 
training  media,  sequencing  instruction,  and  identifying  training 
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equipment  fidelity  requirements.  The  DSS  presents  LSAR  and  other 
analysis-related  data  to  the  analyst  to  assist  in  making  ISD  decisions. 


HI  DAS  TAM 

The  MIDAS  Training  Assessment  Module  (TAM)  is  based  on  the  Instruc¬ 
tional  System  Design  (ISD)  methodology  used  in  DoD  (Smith  and  Banda. 
1989).  The  TAM  capitalizes  on  the  Training  Analysis  Support  Computer 
System  (TASCS):  but  it  also  contains  a  more  robust  training  domain  knowl¬ 
edge  representation  and  it  concentrates  on  output  pertinent  to  designers 
of  both  training  systems  and  aircraft  systems.  The  Al-based  tool  rapid¬ 
ly  isolates  the  most  significant  training  impacts  of  conceptual  vehi¬ 
cles.  and  allows  designers  to  ask  pertinent  "what-if"  questions  about 
changes  to  mission  requirements,  cockpit  equipment,  operator  skills,  or 
training  budgets. 


3.3  EVALUATION  CRITERIA 

Oesign  evaluation  criteria  such  as  those  described  by  Kerchner 
(1991)  and  Booher  and  Hewitt  (1990)  were  applied  to  the  various  models 
under  consideration.  These  included  criteria  for  assessing  the  fully 
implemented  system  and  the  feasibility  of  development: 

•  Ease  of  use:  the  simplicity  of  application.  Amount  of  train¬ 
ing  required  to  operate  and  use  the  system.  Applicability  to 
concept  exploration  phase  of  the  acquisition  process. 

•  Operating  cost:  resources  needed  to  use  the  system.  Data 
availability.  Monetary  resources  as  well  as  data  require¬ 
ments.  equipment  needed,  personnel  and  time. 

•  Technical  feasibility:  the  analytical  methods,  hardware,  and 
software  can  be  created  or  acquired  and  assembled  in  a  manner 
to  meet  functional  requirements,  and  to  provide  quality 
results  for  the  intended  application. 

•  Operational  feasibility:  the  system  can  meet  the  principal 
operating  requirements  of  its  users,  i.e.,  interface  with 
other  tools,  and  produce  the  required  information  in  a  timely, 
useful  manner. 
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•  Economic  feasibility:  development  costs,  consistent  with 
budgetary  constraints. 

Candidates  in  each  of  the  tool  classes  were  evaluated  against  the 
criteria  on  a  High-Low  scale,  with  High  denoting  a  good  fit  (i.e.,  easy 
to  use,  available  data,  low  equipment  costs,  compatibility  with  design 
phase,  etc.)  and  Low  denoting  hard  to  use  (high  training  burden),  high 
cost  equipment,  or  high  development  costs,  technical  risks,  etc.). 

Figure  8  presents  the  results  of  this  evaluation. 

3.4  DEMONSTRATION  OF  THE  TACHSI  CONCEPT  THROUGH  AN  IDEAL  EXAMPLE 

Demonstrating  a  subset  of  the  tools  previously  discussed  may 
clarify  how  TACHSI  could  be  applied  to  concept  design.  The  IDEAL 
methodology  includes  many  of  the  tools  discussed  in  the  preceding  sec¬ 
tion.  The  example  presented  here  demonstrates  its  use  in  conducting 
trade  studies  between  human  and  automated  components  in  an  aircraft 
cockpit.  Alternative  concepts  are  modeled  as  different  processors, 
i.e.,  mechanisms  in  IDEF0  and  SAINT,  and  with  different  performance 

functions  in  the  performance  database. 

The  IDEAL  methodology  is  applicable  to  the  analysis  of  many  types 
of  systems.  To  illustrate  some  of  IDEAL’S  potential,  the  following 
example  is  provided.  Consider  a  single-crew  aircraft  equipped  with  an 
intelligent  subsystem  called  the  pilot's  associate.  The  avionics  suite 
consists  of  three  multipurpose  video  displays,  an  expert  system  data¬ 
base.  and  a  protectea-data  manager  (figure  9).  During  a  mission,  the 
pilot  and  pilot's  associate  are  responsible  for  interrogating  the  air¬ 
craft's  subsystems  for  status  information.  The  interrogation  requests 
are  associated  with  either  standard  subsystem  procedures  or  with  special¬ 
ized  mission  events.  For  example,  a  specialized  event  could  be  a  lock- 
on  indication  meaning  that  the  launch  of  an  enemy  missile  is  eminent. 
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SAINT,  as  a  stand-alone  simulation  model,  requires  considerable  expertise  to  set  up  and 
interpret.  Within  the  context  of  TACHSI,  set-up  would  be  automatic,  and  output  would  be  run 
through  a  postprocessor  to  meaningfully  format  results. 

H  =  High  acceptance 
L  =  Low  acceptance 


FIGURE  8:  EVALUATION  OF  REPRESENTATIVE  HMPT 
METHODS  FOR  INCLUSION  IN  TACHSI 
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Processors 
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FIGURE  9:  AVIONICS  SUITE  REPRESENTATION  FOR  IDEF  DEMONSTRATION 


In  response,  the  pilot  might  have  to  determine  the  most  effective  type 
of  countermeasure  to  be  used. 

Depending  on  the  request,  the  processor  associated  with  each  dis¬ 
play  has  to  perform  up  to  four  tasks  for  each  request.  The  tasks  may  be 
one  of  three  types.  The  first  is  a  simple  request  for  information  to  be 
presented  on  the  display.  The  second  requires  the  display  processor  to 
access  appropriate  information,  perform  computations,  establish  the  dis¬ 
play  format  through  an  expert  system,  and  display  the  information.  The 
third  requires  the  display  process  to  access  protected  information 
through  a  data  manager,  obtain  the  display  format  through  an  expert 
system,  and  present  the  information  using  specialized  graphics  capabili¬ 
ties.  Although  both  the  pilot  and  the  pilot’s  associate  may  request  any 
of  the  task  types,  the  pilot  most  frequently  requests  the  specialized 
procedures,  and  the  pilot's  associate  is  most  likely  to  make  the  simple 
display  requests. 

Once  on  the  avionics  bus.  the  requests  for  a  single  queue  are 
assigned  to  the  next  available  display  processor.  The  request  remains 
in  the  interface  buffer  while  the  display  processor  performs  the  first 
of  the  tasks  within  the  request.  If  the  request  contains  additional 
tasks,  the  display  processor  performs  the  appropriate  actions.  When  all 
tasks  for  the  request  are  completed,  the  request  is  deleted  from  the  buf 
fer,  and  the  display  processor  waits  for  the  next  request  in  the  queue. 

The  goal  of  the  demonstration  model  is  to  determine  if  a  proposed 
design  is  adequate  to  effectively  process  the  requests  for  information 
made  by  the  pilot  and  pilot's  associate  during  a  mission  segment.  Per¬ 
formance  can  be  measured  in  various  ways  depending  on  the  system's  objec 
tives,  and  which  system  aspects  are  being  studied.  For  the  cockpit  simu 
lation,  the  performance  parameters  have  been  selected  to  monitor  the 
information  flow  through  the  system.  These  parameters  include  the 
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number  of  requests  that  are  waiting  to  be  processed  by  various  compo¬ 
nents  of  the  avionics  system,  the  length  of  time  that  the  requests  wait 
in  queues  for  processing,  the  length  of  actual  processing  time,  and  the 
amount  of  time  during  the  mission  that  the  various  system  components  are 
processing  information. 

The  IDEAL  methodology  provides  the  approach  for  structuring  the 
definition  of  the  problem  and  for  generating  the  simulation  model.  The 
IOEF0  model  of  the  system  is  provided  in  section  3.4.1  and  the  SAINT 
simulation  network  is  provided  in  section  3.4.2. 

3.4.1  IDEF0  MODEL  OF  PILOT  ASSOCIATE 

This  example  contains  a  three-level  IDEF  decomposition.  Level  A-0 
is  the  context  level.  Four  processes  are  involved  at  level  A-0.  and 
three  of  these  are  decomposed  further.  Diagrams  and  associated  descrip¬ 
tions  are  in  figures  10  through  14. 

3.4.2  SAINT  MODEL  OF  PILOT  ASSOCIATE 

Within  both  IDEAL  and  TACHSI.  the  IDEFo  model  is  the  foundation  for 

developing  a  simulation  model  of  the  system  using  the  SAINT  language. 

The  development  of  the  simulation  model  is  a  two-step  process.  The 
first  step  develops  the  basic  network  representing  the  system's  process 
flow  and  the  second  step  is  to  overlay  dynamic  characteristics  onto  the 
network.  The  full  SAINT  network  for  the  pilot's  associate  example  is 
shown  in  figure  15,  spanning  two  pages. 

The  development  of  the  simulation  model  begins  by  generating  a  top- 
level.  single-node  network  based  on  the  A-0  diagram.  The  next  step  is 
to  detail  this  top-level  model  to  correlate  with  the  A-0  diagram.  This 
level  of  the  network,  represented  by  the  shaded  area  in  figure  15,  is 
bounded  by  the  dummy  nodes  numbered  20  and  21. 
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The  goal  of  the  pilot  support  system  being  analyzed  is  to  provide 
aircraft  operational  status  information  to  the  pilot.  The  information 
presented  is  categorized  into  two  types.  The  largest  amount  of  informa¬ 
tion  provided  to  the  pilot  is  that  which  indicates  the  operational  sta¬ 
tus  of  the  basic  subsystems  of  the  aircraft.  The  second  type  of  informa 
tion  is  that  which  indicates  the  mission  events  or  the  environment  in 
which  the  aircraft  is  operating.  This  status  information  is  collected 
from  its  sources  within  the  aircraft,  formatted,  and  presented  to  the 
pilot  via  a  set  of  display  units. 

The  requests  which  drive  the  displays  are  generated  by  both  the 
pilot  and  the  pilot’s  associate.  The  systems  which  work  together  to 
obtain,  adjust,  and  display  the  information  are  the  display  processors, 
expert  system  database,  and  protected  data  manager. 


FIGURE  10:  A-0  PROCESS  REQUESTS  FOR  INFO  DISPLAYS 
(CONTEXT) 
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The  overall  process  involved  in  getting  the  required  information  to 
the  pilot  is  represented  as  four  major  functions.  It  is  assumed  that 
before  a  request  can  be  processed,  it  must  be  assigned  to  a  dedicated 
display  which,  in  turn,  has  a  specific  process  associated  to  the  display 
unit.  Therefore,  the  first  function  results  in  the  assignment  of  a 
specific  request  to  a  specific  display  unit. 

Once  the  display  assignment  has  been  made.  The  Access  and  Prepare 
Info  function  interprets  the  requirements  of  the  request,  accesses  the 
necessary  information  from  within  the  aircraft,  and  establishes  the 
guidelines  for  displaying  the  information.  The  Present  Info  to  Pilot 
function  manipulates  the  information  to  satisfy  the  requirements  of  the 
display  format  and  then  presents  the  information  to  the  pilot  using  the 
display  unit  which  has  been  assigned  to  the  request. 

Finally,  when  the  current  request  has  been  fully  satisfied,  the 
display  unit  and  the  associated  process  must  be  freed  so  that  it  can  be 
assigned  to  the  next  request  in  the  queue. 
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FIGURE  11:  AO  PROCESS  REQUESTS  FOR  INFO  DISPLAYS 
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The  requests  for  information  are  generated  by  two  sources:  the 
pilot  and  the  pilot  associate.  These  requests  are  based  on  a  need  for 
understanding  the  status  of  the  standard  aircraft  subsystem  operations 
or  the  status  of  specialized  mission  events  define  the  environment  that 
though  which  the  aircraft  is  flying.  As  the  requests  are  generated, 
they  are  placed  in  a  queue  to  be  processed  by  the  aircraft’s  computer 
system.  The  first  requirement  for  processing  a  request  is  to  have  a 
dedicated  display  and  processor  assigned  to  the  request.  If  no  display 
unit  is  available,  the  request  in  placed  in  a  queue  until  a  display  does 
become  available.  The  Track  Display  Availability  function  is  respon¬ 
sible  for  monitoring  the  availability  of  the  various  displays  and  let¬ 
ting  the  Assign  Request  function  know  when  a  display  unit  is  available 
for  the  next  request. 


FIGURE  12:  A1  ASSOCIATE  REQUEST  TO  DISPLAY/ 
PROCESSOR 
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Once  the  next  request  in  the  queue  has  been  assigned  to  a  display 
unit,  the  system  is  ready  to  process  the  request.  The  first  step  is  to 
identif  :he  type  of  information  that  is  associated  with  the  request. 

The  standard  request  involves  information  associated  with  the  normal 
operation  of  the  aircraft.  For  this  situation,  the  assigned  processor 
is  able  to  directly  access  the  necessary  information  and  hand  it  over  to 
the  expert  system  for  the  actual  processing  and  display.  For  the  spe¬ 
cialized  information  requests,  the  processor  works  through  the  data  man¬ 
ager  to  access  the  appropriate  information  and  performs  the  appropriate 
computations  before  handing  control  over  to  the  expert  system. 


FIGURE  13:  A2  ACCESS  AND  PREPARE  INFO 
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If  the  information  to  be  presented  is  the  standard  information,  the 
display  processor  simply  displays  the  information  as  represented  within 
the  pilot's  request  function.  However,  if  the  information  to  be  present¬ 
ed  is  of  the  special  type,  the  expert  system  first  establishes  the  for¬ 
mat  that  is  to  be  used  to  display  the  information.  Once  the  format  has 
been  established,  the  display  processor  then  presents  the  information  to 
the  pilot. 

As  was  defined  for  the  requests,  each  request  may  involve  up  to 
four  individual  tasks.  The  Check  If  Request  is  Completed  function 
represents  the  process  of  checking  to  verify  that  all  the  tasks  have 
been  completed.  If  the  request  is  completed,  control  goes  to  the  AO. 4 
task,  which  clears  the  appropriate  subsystems  so  they  are  available  for 
another  request.  If.  however,  more  tasks  remain  to  complete  the 
request,  control  is  returned  to  function  A2.1  where  task  processing 
begins . 


FIGURE  14:  A3  PRESENT  INFO  TO  PILOT 
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FIGURE  1 5:  SAINT  NETWORK  NODES  FOR  PILOT'S  ASSOCIATE 
CONCEPT  DEMONSTRATION 


For  illustration  within  this  example,  the  nodes  30.  31.  and  32  are 
decomposed  to  one  more  level  of  detail.  These  nodes  correspond  to  the 
A0.1,  AO. 2,  and  AO. 3  functions  of  the  I DE F0  model.  Figure  15  represents 
the  next  level  of  detail  for  the  A0.1  function;  region  A2  represents  the 
next  level  of  detail  for  the  AO. 2  function;  and  region  A3  represents  the 
next  level  of  detail  for  the  AO. 3  function.  Each  of  these  subnetworks 
is  surrounded  by  dummy  nodes  in  order  to  control  the  information  flow  so 
that  the  subnetworks  can  be  represented  in  a  modular  manner. 

When  each  of  the  simulation  subnetworks  are  linked  together  as 
represented  in  figure  15.  the  correlation  between  the  I DEF0  and  the 
SAINT  network  model  is  obvious. 

The  complete  definition  of  the  SAINT  network  requires  that  dynamic 
information  be  overlayed  onto  the  basic  network.  This  information  is 
documented  on  the  Performance  Data  Base  ( PDB)  form  illustrated  in  figure 
16.  One  form  is  needed  for  each  of  the  lowest  level  IDEFo  functions 

which  has  a  corresponding  node  in  the  SAINT  network. 

Within  TACHSI .  the  SAINT  nodes  would  be  generated  automatically, 
including  the  dummy  nodes  used  to  control  the  flow  of  information.  The 
PDB  form  would  be  a  pop-up  form  which  would  be  populated  from  the  PDB. 
when  possible,  or  by  the  user  in  other  cases. 

3.4.3  SAMPLE  OUTPUT 

Within  TACHSI.  the  SAINT  simulation  model  is  constructed  to  study 
the  system's  performance.  Performance  is  measured  in  various  ways 
depending  on  the  system's  objectives  and  the  critical  design  variable. 
For  this  cockpit  simulation,  the  designers  are  interested  in  determining 
if  the  avionics  design  is  adequate  to  handle  the  requested  load  for  a 
mission  segment.  To  accomplish  this  analysis,  several  performance 


FIGURE  16: 


PERFORMANCE  DATABASE  FORM  FOR  PILOT’S 
ASSOCIATE  CONCEPT  DEMONSTRATION 
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metrics  are  used.  The  first  metric  is  to  look  at  the  length  of  the 
request  queue  throughout  the  mission  segment.  This  metric  corresponds 
to  the  length  of  the  queue  at  task  3.  The  information  on  queue  length 
over  time  can  be  requested  by  TACHSI  at  SAINT  run-time.  Figure  17a 
graphs  the  queue  length  as  a  function  of  time,  using  the  information  in 
the  Queue  Monitoring  Report  file.  It  can  be  seen  that  the  queue  was 
never  longer  than  four  requests,  and  that  was  only  for  a  very  short 
time.  The  designers  could  then  decide  whether  the  queue  lengths  are 
acceptable. 

Similarly,  the  queues  of  task  8  and  9  could  be  monitored  to  deter¬ 
mine  the  queue  lengths  of  the  processors  waiting  to  use  the  expert 
system  and  waiting  for  the  data  manager  (figures  17b  and  17c,  respec¬ 
tively). 

To  study  the  length  of  time  that  the  request  waits  in  queue,  a  task 
interval  statistic  can  be  used  to  generate  a  measure  of  the  time  that 
the  request  (packet)  waits  in  queue.  The  statistics  gathered,  and  a 
histogram  of  the  information  produced  by  C-SAINT,  are  shown  in  figure 
18.  It  can  be  seen  that  although  the  average  wait  in  queue  was  about 
four  seconds,  one  packet  had  to  wait  for  over  19  seconds. 

The  Resource  Utilization  Report,  figure  19.  tallies  the  busy  and 
idle  times  of  each  of  the  resources.  This  can  be  used  as  one  measure  of 
a  resource's  workload. 

The  possibilities  of  other  kinds  of  metrics  one  might  collect  are 
almost  endless:  numbers  of  requests  serviced  by  each  display  processor 
can  be  collected  using  Number  Statistics  on  task  13.  14,  and  15;  dura¬ 
tion  of  each  separation  transaction  can  be  collected  with  Interval  Sta¬ 
tistics  between  task  5  and  task  11;  individual  requests  can  be  traced 
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FIGURE  19:  RESOURCE  UTILIZATION  REPORT 


through  the  system  using  the  Detailed  Iteration  Report;  and  information 
on  the  packets  at  each  task  can  be  collected  using  the  Information 
Monitoring  Option  for  that  task. 
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4.0  SYSTEM  REQUIREMENTS 


The  HSD/XR  IDEF  analysis  of  the  MPTS  issues  in  the  system  acquisi¬ 
tion  process  (documented  in  Rossmeissel  et  al..  1990),  and  a  review  of 
the  more  promising  HSI  tools,  support  the  system  requirements  presented 
in  this  section.  The  IDEFq  methodology,  in  addition  to  being  proposed 

as  a  component  of  TACHSI.  is  used  as  a  system  description  tool  to  iden¬ 
tify  the  inputs,  outputs,  controls,  mechanisms,  and  system  functions 
from  the  viewpoint  of  an  HSI  analyst.  The  following  sections  describe 
the  TACHSI  environment  through  hierarchical  IDEF  diagrams,  and  outline 
the  intended  functions,  users/mechanisms,  information,  and  hardware 
environment  in  which  it  will  be  used. 

4.1  TACHSI  PROCESS  DESCRIPTION 

TACHSI.  a  Tool  for  Analyzing  Concepts  in  Human  Systems  Integration, 
supports  the  system  acquisition  process  through  a  family  of  flexible 
MPTS  methods  and  databases.  Tool  application  is  focused  during  the 
concept  exploration  phase,  but  its  utility  lends  itself  to  other  phases 
as  well.  Most  of  the  components  exist  as  independent  automated  methods, 
and  the  TACHSI  framework  provides  structures  for  linking  the  methods 
through  shared  information  flows  and  a  common  user  interface. 

The  master  context  in  which  TACHSI  is  used  is  shown  in  figure  20. 
an  IDEFo  diagram  consisting  of  one  process  box,  with  several  inputs. 

outputs,  mechanisms,  and  controls.  Note  that  the  system  provides  feed¬ 
back  to  design  alternatives  through  the  results  of  concept  trades,  and 
HSI  analyses.  Mechanisms  include  persons/organizations  in  government 
and  industry.  Controls  or  constraints  to  the  analysis  include  official 
policies,  directives  and  guidelines,  and  resource  constraints. 
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Note  that  the  role  and  description  of  mechanisms  is  very  important 
within  TACHSI.  They  become  interchangeable  agents,  and  permit  great 
flexibility  in  evaluating  alternative  designs. 

The  contents  of  the  inputs,  outputs,  mechanisms,  and  controls  for 
the  TACHSI  context  diagram  are  analogous  to  those  feeding/resulting  from 
the  Concept  Exploration  process  box  in  the  HSD/XR  IDEF  model. 

Integrating  existing  tools  under  a  common  architecture  was  pre¬ 
ferred  to  developing  a  completely  new  approach.  Properly  designed,  a 
modern  architecture  will  efficiently  bridge  interconnections  among 
models  and  methods.  The  use  of  existing  tools  such  as  IDEF  and  SAINT 
within  the  integrated  architecture  increases  the  operational  feasibil¬ 
ity.  since  the  tools  have  some  credibility  established.  The  structure 
permits  flexibility  in  adding  new  tools  to  the  architecture.  As  the 
tool  kit  expands,  the  user  will  be  able  to  analyze  a  wider  range  of 
issues  (e.g.,  concept  issues  such  as  mission  effectiveness  and  a  larger 
class  of  users,  beyond  just  the  MPT  community,  may  benefit.  An  intelli¬ 
gent  interface  among  the  tools  also  reduces  the  user-training  burden. 

4.2  FUNCTIONAL  REQUIREMENTS 

Figure  21  contains  a  second-level  IDEF  process  decomposition  of 
TACHSI.  The  activity  boxes  correspond  to  the  basic  functions  provided 
by  TACHSI.  Figure  22  contains  a  hierarchical  description  of  the  basic 
system  functions,  corresponding  to  decomposed  IDEF  activity  boxes. 

4.3  INFORMATION  REQUIREMENTS 
INPUTS 

Specifying  task  data  is  the  primary  driver  in  preparing  for  many 
MPT  analysis  in  TACHSI.  The  desired  level  of  task  decomposition,  the 
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FIGURE  21 :  LEVEL  AO  TACHSI  PROCESS  DIAGRAM 


[AO]  Invoke  TACHSI 


FIGURE  22: 


[Al]  Describe  System 

[All]  Review  Predecessor  System 

[A12]  Oefine  Process  Decomposition 

[A13]  Define  Analysis  Objectives 

[A2]  Generate  Performance  Database 

[A21]  Review  Existing  Models 

[A22]  Oefine  Synamic  Task  Information 

[A23]  Oefine  System  Information  and  Resource 
Attributes 

[A24]  Define  Environmental  Conditions 
[A3]  Construct  System  Simulation  Model 
[A31]  Define  Human  Operator  Model 
[A32]  Define  Machine  Model 
[A33]  Select  Simulation  Techniques 
[ A4]  Exercise  Models 
[A5]  Evaluate  Results 

[A51]  Select  Output  Views 

[A52]  Evaluate  Against  Criteria 

[A53]  Recommend  Change/Complete  Analysis 

THREE-LEVEL  FUNCTION  DECOMPOSITION  FOR 
TACHSI 
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source  of  data  (i.e..  access  to  predecessor  system),  or  the  presence  of 
expert  system  aids  will  significantly  alter  the  time  needed  to  describe 
the  nature  of  HSI  under  study.  Consistency  across  descriptions  is  neces¬ 
sary  to  ensure  use  across  analysis  models.  The  IDEF/SAINT  activity  task 
linkage  is  locked,  but  the  link  to  LSAR  data  for  the  ISD/LSAR  DSS  will 
be  harder  to  enforce  without  a  predefined  task  description  vocabulary. 


OUTPUTS 

TACHSI  includes  capabilities  to  prepare  both  standard  and  ad  hoc 
analysis  reports.  The  library  of  standard  reports  will  evolve  as  tools 
are  added  and  user  requests  expand.  Contents  of  standard  reports 
incl ude: 


•  design/analysis  graphs  supporting  system  and  MPT  tradeoff 
studies,  high  drivers  identification,  and  cost  assessment  will 
be  standard.  SAINT  simulation  output  will  be  stored  in  data¬ 
bases  for  subsequent  analysis.  Examples  include 

mechani sm/ resource  utilization; 

•  process  diagnostic  aids  such  as  user  audit  trails,  model 
activity  logs,  inconsistencies  in  information  flow,  or  flags 
pointing  to  inconsistencies  in  HSI  model  structures;  and 

•  analyses  formatted  to  interface  directly  with  IMPACTS 
reporting  requirements  (e.g..  IMPACTS  Program  Plan,  etc.) 

Reporting  and  charting  features  represent  the  primary  communication 
device  among  system  developers  throughout  the  acquisition  process. 

TACHSI  reports  and  graphs  will  support  this  process. 


4L.4  -SISIEMJI1E&S 

The  HSD/XR  IOEF  study  identified  various  mechanisms  and  their  inter¬ 
actions  at  each  process  activity.  In  the  pre-Milestone  I  activities 
(decompositions  of  A1  and  A2  activities)  where  system  level  concepts  are 
explored  and  defined,  the  Air  Force  players  include  the  MAJCOM.  Training 
command  (ATC).  ASO  planning  organizations  and  SPOs  if  they  exist,  the 
support  commands,  and  the  AF  Office  of  Technical  Assessment  (AFOTA). 
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Industry/contractors  would  also  be  mechanisms.  User  involvement  for  the 
three  level -two  concept  exploration  activities  which  drive  MPTS 
decisions  are  shown  in  figure  23. 


Meehan  is  ms/Users 
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FIGURE  23:  MECHANISM  IN  MPTS-DRIVEN  ACTIVITIES  IN 
CONCEPT  EXPLORATION 


4.5  PLATFORM  REQUIREMENTS 

No  single  platform  configuration  stands  out  as  the  overriding 
preferred  choice.  Tool  users  prefer  a  platform  with  a  graphical  windows 
and  mouse  interface,  network  access  to  shared  databases,  and  device¬ 
independent  applications.  Most  existing  HMPT  applications  provide  few 
of  these  capabilities,  with  most  residing  on  non-networked  PC/DOS 
platforms.  The  ISD/LSAR  OSS  is  a  networked  DOS  application. 
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The  move  toward  open  system  architectures  over  the  next  few  years 
will  make  it  easier  to  comply  with  these  preferences.  In  the  interim, 
however,  the  platform  and  compatibility  requirements  listed  in  figures 
24  and  25  are  starting  points. 


Hardware 

Macintosh  or  UNIX 

Software 

Windows  Environment 

•  X-Wmdows  on  UNIX 

•  Mouse  Interface 

Database 

Geometric/Graphic  Object  Database 

•  4th  Dimension  RDBMS  on  Mac 

•  SYBASE  or  Informix  on  UNIX 

FIGURE  24:  TACHSI  PLATFORM  REQUIREMENTS 


Computer-Aided  Acquisition  and  Logistics  Standards  (CALS)  Compliance 
Data  Interchange  Standards 

*  IGES  -  International  Graphics  Exchanges  Specification  (for  two  and 
three  dimensional  geometry) 

*  STEP  -  ISO  Standard  for  the  Exchanges  of  Product  Model  Data 

*  PDES  -  Product  Data  Exchange  Standards 

Open  System  Standards 

*  GOSIP  •  Government  Open  System  Interconnection  Profile 

*  POSIX  -  Portable  Operating  System  Interface  for  Computing 
Environments 


FIGURE  25:  COMPATIBILITY  REQUIREMENTS 
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Several  data  standards  apply  to  product,  mechanical  design  and 
logistics  data.  These  include  POES.  IGES,  STEP,  and  CALS. 

Standard  interfaces  to  permit  product  data  exchange  with  models  and 
engineering  design  systems  should  conform  to  POES  (Product  Data  Exchange 
Standards).  This  will  permit  communication  between  different  CAD/CAM/ 
CAE  design  systems  among  government  and  contractor  sources/users. 

The  Initial  Graphics  Exchange  Specification  (IGES)  defines  a  neu¬ 
tral  format  for  two-dimensional  and  three-dimensional  geometry.  Trans¬ 
lators  convert  proprietary  internal  data  formats  into  and  out  of  the 
IGES  format,  but  fall  short  of  complete  geometry  transfer  between  sys¬ 
tems  without  human  intervention. 

The  ISO  Standard  for  the  Exchange  of  Product  Model  Data  (STEP),  in 
conjunction  with  POES,  addresses  all  phases  of  the  product  life  cycle, 
with  information  on  shape/size,  configuration,  function,  and  physical 
and  operational  characteristics. 

Use  of  product  data  exchange  standards  will  ensure  compliance  with 
CALS  requirements,  as  MilStd  1840A  is  applied  to  new  DoD  procurement 
contracts.  This  will  also  permit  cost-effective  communication  of  pro¬ 
duct  data  (e.g.,  system  geometries,  subassembly  locations  and  character¬ 
istics)  among  government  and  industry/contractor  personnel.  Access  to 
graphical  data  will  facilitate  analysis  by  operator  graphic  and  CAD 
models,  and  ensure  that  analyses  are  performed  on  the  most  current,  con¬ 
sistent.  and  accurate  product  description  data. 
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5.0  RECOMMENDATIONS 


This  section  describes  the  process  to  be  employed  in  Phase  II  for 
developing  the  demonstration  prototype  for  the  Tool  for  Analyzing  Con¬ 
cepts  in  Human  Systems  Integration  (TACHSI).  Section  3.1  presents  an 
overview  of  the  approach,  and  sections  3.2  through  3.5  detail  the 
approach  used  in  each  of  the  four  Phase  II  tasks. 

5.1  OVERVIEW  OF  APPROACH 

The  overall  approach  to  developing  the  demonstration  prototype  for 
TACHSI  will  apply  a  proven  system  development  philosophy  and  standards, 
procedures,  tools,  and  techniques  employed  in  the  past.  These  include 
state-of-the-art  software  life  cycle  methods,  open  system  standards, 
structured  a:.;  ysis  and  design,  joint  application  development  (JAD)  and 
rapid  prototyping  techniques,  and  data  modeling  techniques.  The  basic 
development  approach  follows  the  steps:  Design.  Develop.  Test,  and 
Document.  TACHSI  design  activities  are  encompassed  in  Task  1;  develop¬ 
ment  and  test  in  tasks  2  and  3.  Documentation  is  included  throughout 
the  process,  starting  with  specifications  in  Task  1.  followed  by  ongoing 
updates  during  development,  and  concluding  with  the  final  form  of  each 
in  Task  4. 

The  context  and  first-level  decomposition  of  the  TACHSI  design 
approach  is  presented  as  two  IOEF0  diagrams  in  figures  26  and  27, 

respectively.  Note  that  right-pointing  arrows  represent  inputs,  left¬ 
pointing  arrows  denote  output:  down-pointing  arrows  are  constraints  or 
controls  within  the  process.  The  mechanism,  the  VRI  development  team, 
applies  to  all  processes. 


FIGURE  26:  IDEF  CONTEXT  DIAGRAM  FOR  TACHSI  SYSTEMS 
DEVELOPMENT  APPROACH 


EXHIBIT  27:  TACHSI  SYSTEMS  DEVELOPMENT  APPROACH 
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During  the  Phase  II  TACHSI  R&D  effort,  VRI  will  apply  its  software 
engineering  expertise,  and  our  library  of  software  development  tools  to 
ensure  the  greatest  functionality  possible  in  the  demonstration  proto¬ 
type.  For  example.  VRI  will  use  Computer  Aided  Software  Engineering 
(CASE)  tools,  such  as  the  IDEFjx  feature  within  Design/IDEF.  throughout 

the  process  to  develop  the  data  model  and  database  specification  docu¬ 
ment  during  Task  1.  CASE  tools  will  also  be  used  to  document  subsystem 
specifications  also  in  Task  1.  These  specification  documents  will  be 
compiled  and  updated  as  necessary  throughout  Phase  11  to  ensure  consis¬ 
tency  with  the  actual  implementation. 

VRI  will  apply  structured  analysis  and  design  techniques  early  in 
the  process  to  support  modular  construction,  rapid  development,  and  ease 
of  migration  in  the  future.  In  addition.  VRI  will  use  commercial  off- 
the-shelf  (COTS)  products  where  advantageous  to  the  development  effort, 
and  where  the  decision  will  not  require  the  purchase  of  additional, 
expensive  licensed  products  by  the  AF  users. 

Quality  user  and  system  documentation  is  critical  to  the  life  of  a 
system,  but  the  cost  of  producing  this  documentation  cannot  be  ignored. 
The  DoD  STD  7935A  Military  Standard  for  DoD  Automated  Information  System 
(AIS)  Documentation  contains  guidelines  for  the  minimum  set  of  documen¬ 
tation  needed  for  AIS  of  varying  degrees  of  complexity.  The  proposed 
cost,  level  of  effort,  complexity  and  priority  for  TACHSI  suggest  only 
that  an  End  User  Manual  is  required.  However,  a  Functional  Description, 
which  includes  a  Subsystem  Specification,  and  a  Database  Specification, 
are  invaluable  to  the  success  of  the  effort.  The  documents  will  be  com¬ 
posed  primarily  of  the  output  from  CASE  tools,  i.e.,  data  flow  diagrams, 
entity  relation  diagrams,  etc. 

The  central  core  of  TACHSI  is  the  integration  architecture,  which 
includes  the  interface  to  the  user,  the  HSI  models,  and  the  databases. 
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The  details  of  this  integration  will  be  outlined  in  the  TACHSI  Integra¬ 
tion  Protocol  (TIP),  documented  in  Task  1  and  implemented  in  Task  2. 

The  actual  HSI  and  planning  models,  i.e.,  SAINT.  IDEFo,  etc.,  are  driven 

from  the  TIP  implementation.  TIP’s  design  will  reflect  the  necessary 
functions  which  supports  ASD  planners,  while  retaining  modularity  and 
flexibility  to  accommodate  additional  models  in  the  future.  The  tip 
description  will  identify  the  basic  system  building  blocks,  e.g..  pro¬ 
cess.  input,  mechanism,  output,  constraint,  performance  function,  etc., 
and  define  the  interfaces  needed  to  specify,  store,  and  use  them  in 
conducting  planning  studies.  The  mapping  from  IDEF  to  SAINT  for  task 
networks  of  varying  complexity  will  be  accomplished  in  stages.  The 
first  stage  will  assume  a  deterministic  task  flow  without  branching; 
subsequent  phases  will  address  the  impact  of  more  complex  task  branching 
conditions,  and  will  modify  the  building  blocks  and  protocol 
accordingly. 

After  TIP  is  implemented  in  Task  2.  selected  individual  HSI  models 
will  be  incorporated  into  TACHSI  in  Task  3.  IDEF0 ,  SAINT  and  the  Per¬ 
formance  database  interface  will  be  will  be  added  first,  followed  by 
Isoperformance.  Simple  task  networks  will  be  implemented  first,  fol¬ 
lowed  by  increasingly  complex  networks.  Implementation  tradeoffs 
between  increased  network  complexity  versus  expanded  HSI  analysis  func¬ 
tionality  will  be  made  during  Task  3.  in  concert  with  feedback  from  user 
groups  and  the  AF  sponsor.  User  feedback  will  play  a  critical  role  in 
this  task,  as  interim  demonstration  prototypes  of  TACHSI  will  be  made 
available  for  evaluation.  Several  trips  are  planned  to  ASD  to  solicit 
this  feedback. 

Task  4  will  synthesize  the  results  of  the  demonstrations  and  evalua¬ 
tions  and  prepare  a  roadmap  for  operational  system  development  and 
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potential  commercialization  in  Phase  III.  The  final  report  will  be 
prepared,  presented,  and  revised  during  Task  4. 

Figure  28  contains  a  schedule  for  completing  the  four  tasks  in  the 
Phase  II  approach.  An  18-month  project  duration  is  proposed  to  include 
frequent  trips  to  the  sponsor.  These  include  the  standard  kick-off  and 
end-of -project  meetings.  Also  included  is  a  major  technical  interchange 
meeting  to  present  the  system  and  database  specification  documents  after 
completion  of  Task  1.  and  to  get  AF  review  and  approval  prior  to  the 
start  of  the  development  efforts  in  Tasks  2  and  3.  In  addition,  four 
trips  are  planned  to  ASD  to  solicit  user  feedback  at  various  stages  in 
the  TACHSI  prototype  development  effort.  These  are  scheduled  to  occur 
at  the  end  of  Task  2.  and  at  subphases  within  Task  3  as  different  HSI 
models  and  functionality  are  added.  Major  milestones  are  included  in 
the  schedule  to  correspond  to  delivery  of  interim  and  final  reports. 

Air  Force  support  should  include: 

.  machine  readable  and  hard  copy  source  code  in  FORTRAN  for  the 
C-SAINT  simulation  model; 

.  machine  readable  and  hard  copy  source  code  in  Pascal  for  the 
Isoperformance  software  package; 

•  access  to  CSERIAC  data,  as  needed,  to  populate  the  performance 
database;  and 

•  user  feedback  via  technical  interchange  meetings  and  interim 
demonstrations  regarding  desirable  features  of  the  software, 
e.g.,  desired  characteristics  of  the  TACHSI  user  interface. 
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The  purpose  of  this  task  is  to  establish  the  functional,  environ¬ 
ment.  and  database  specifications  of  TACHSI  in  sufficient  detail  to  pro¬ 
ceed  with  prototype  system  development.  The  results  of  Phase  I.  and 
available  documentation  on  selected  HS 1  tools,  will  provide  the  input  to 
the  process.  The  task  will  generate  three  specification  documents  which 
define  the  workstation  environment  for  the  prototype  system,  the  func¬ 
tional  and  subsystem  characteristics,  and  the  databases.  The  documents 
serve  as  controls  in  subsequent  tasks.  The  primary  control  within  this 
task  are  DoD  standards  regarding  Open  Systems  Integration  and  Corporate 
Information  Management  technical  architectures. 

The  three  subtasks  within  task  1  focus  on  producing  each  specifica¬ 
tion  document.  As  indicated  in  figure  28.  these  subtasks  will  be  con¬ 
ducted  concurrently,  with  considerable  interaction  among  the  developers. 

5.2.1  WORKSTATION  ENVIRONMENT  SPECIFICATION 

Specifying  the  workstation  environment  is  a  nontrivial  task,  in 
that  it  may  have  considerable  impact  on  the  development  effort  and  the 
ease  in  migrating  toward  the  operational  system  in  Phase  III.  As  noted 
in  the  Phase  I  report,  tool  users  prefer  a  platform  with  a  graphical 
window  and  mouse  interface,  network  access  to  shared  databases,  and 
device-independent  applications.  The  move  in  DoD  toward  open  system 
architectures  over  the  next  five  years  will  make  it  easier  to  comply 
with  these  preferences.  In  the  interim  period  covered  in  this  Phase  II 
effort,  open  systems  are  one  of  several  considerations. 

The  two  platforms  being  considered  are  the  Macintosh  II  running 
Mac/OS  or  a  SUN  Sparc  running  UNIX.  Both  support  a  graphical  user 
interface  and  a  windows  environment.  The  decision  process  will  consider 
these  and  other  factors: 
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•  availability  of  software  development  toolkit  and  prototyping 
widgets; 

•  availability  of  platform  in  ASO  for  demonstration  and  user 
evaluation; 

•  compliance  with  the  Government’s  Application  Portability 
Profile  for  open  system  environments,  as  outlined  in  PB91- 
201004; 

•  cost  of  any  proprietary  packages  (e.g..  Design/IDEF.  or  SQL- 
compatible  relational  database  management  system)  to  the  AF; 
and 

•  software  code  and  COTS  package  portability  from  prototype  to 
operational  platform. 

5.2.2  TACHSI  FUNCTIONAL  SPECIFICATIONS 

The  TACHSI  functional  specifications  will  start  with  this  require¬ 
ments  document  produced  in  Phase  I  and  add  sufficient  detail  to  identify 
specific  system  functions,  subsystems,  and  interactions  among  subsys¬ 
tems.  Documentation  for  selected  HSI  tools,  identified  in  section  3.2, 
will  also  be  used. 

The  resulting  document  will  form  the  basis  for  mutual  understanding 
between  the  TACHSI  developers  and  the  AF  users  for  TACHSI.  It  will 
reflect  the  definition  of  the  system  requirements  and  provide  the  ulti¬ 
mate  users  with  a  clear  statement  of  the  operational  capbility  to  be 
developed.  Its  form  and  content  will  conform  to  DoD  Std  7935  A. 

The  document  will  also  contain  a  system/subsystem  specification  to 
guide  the  development  in  Task  2.  This  will  logically  break  the  system 
into  separate  areas  of  responsibility  or  functions,  where  each  breakdown 
is  composed  of  a  software  unit  or  series  of  units.  The  primary  TACHSI 
functions  which  will  be  described  in  the  system  specification  include: 

(1)  Describe  the  system; 

(2)  Populate  performance  database; 

(3)  Construct  system  simulation  scenario; 
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(4)  Exercise  the  models:  and 

(5)  Evaluate  the  results. 

The  document  will  also  define  the  functions  and  subsystems  for  the 
TACHSI  Integration  Protocol  (TIP).  In  addition,  crosswalks  among  model 
components,  such  as  the  matrix  in  figure  29  which  defines  the  inter¬ 
action  and  component  mapping  between  IDEF  and  SAINT  constructs,  will  be 
prepared  and  included. 

5.2.3  DATABASE  SPECIFICATION 

The  database  specification  will  be  prepared  to  document  the  TACHSI 
entities  and  table  formats  needed  to  support  the  functions,  models,  and 
interfaces  of  the  system.  Entity-relation  diagrams  will  be  created 
using  a  CASE  tool,  such  as  Design/IDEFix .  Specifications  will  be  suf¬ 
ficiently  detailed  to  permit  software  coding  and  database  generation  by 
the  development  group  in  Task  2.  Test  data  sets  will  be  identified  for 
use  throughout  system  development. 

Database  design  implications  of  applicable  data  standards  as  they 
apply  to  product,  mechanical  design  and  logistics  data  ( i . e . .  PDES  (Pro¬ 
duct  Data  Exchange  Standards).  IGES  (Initial  Graphics  Exchange  Speci¬ 
fication).  STEP  (ISO  Standard  for  the  Exchange  of  Product  Model  Data), 
and  CALS  will  be  considered  here.  Direct  interfaces  versus  translation 
routines  will  be  evaluated. 

While  the  use  of  product  data  exchange  standards  will  ensure  compli¬ 
ance  with  CALS  requirements  as  MilStd  1840A  is  applied  to  new  DoD  pro¬ 
curement  contracts,  the  implementation  within  the  prototype  system  is 
viewed  as  less  critical  than  for  the  operational  system.  This  will  also 
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FIGURE  29:  MAPPING  BETWEEN  SAINT  AND  IDEF  COMPONENTS 


permit  cost-effective  communication  of  product  data  (e.g..  system  geo¬ 
metries.  subassembly  locations  and  characteristics)  among  government  and 
industry /con tractor  personnel.  In  the  future,  access  to  graphical  data 
will  facilitate  analysis  by  operator  graphic  and  CAD  models,  and  ensure 
that  analyses  are  performed  on  the  most  current,  consistent,  and 
accurate  product  description  data. 

The  specifications  will  be  presented  to  the  AF  at  a  technical  inter¬ 
change  meeting  at  the  completion  of  Task  1.  Subsequent  development  will 
not  start  until  the  sponsor  agrees  to  the  specifications  outlined  in 
these  documents. 

i.3 . TASK  2:  DEVELQP/TEST  TACHSI  INTEGRATION  PROTOCOL  (TIP) 

The  purpose  of  this  task  is  to  develop  and  test  the  integration 
architecture  for  TACHSI.  The  specification  documents  from  Task  1  will 
serve  as  controls  during  this  task.  The  output  will  be  a  demonstrable 
interface  capable  of  showing  user  interface  screens,  function  selec¬ 
tions.  and  sample  output  capabilities.  Structured  design,  rapid  proto¬ 
typing  and  software  engineering  toolkits  will  be  used  during  the  soft¬ 
ware  development  process.  Test  data,  defined  during  Task  1.  will  be 
used  to  test,  evaluate  and  demonstrate  the  product.  The  TACHSI  frame¬ 
work  and  the  TIP  components  are  shown  in  figure  30.  with  the  TIP 
components  shaded. 

User  interface  screens  will  be  prototyped  and  linked  to  test  data¬ 
sets  for  demonstration.  Special  interface  screens  will  be  constructed 
to  populate  the  performance  database,  and  to  formulate  design  scenarios 
and  identify  design  constraints  for  system  analysis.  Output  formats 
will  be  defined  for  a  set  of  representative  ASD  HSI  tasks. 
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FIGURE  30:  TACHSI  FRAMEWORK  WITH  TACHSI  INTEGRATION 
PROTOCOL  COMPONENTS  SHADED 
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Integrating  existing  tools  under  a  common  architecture  is  preferred 
to  developing  a  completely  new  approach.  Properly  designed,  the  TIP 
architecture  will  efficiently  bridge  interconnections  among  models  and 
methods.  The  use  of  existing  tools  such  as  I DE F  and  SAINT  within  the 
integrated  architecture  increases  the  operational  feasibility,  since  the 
tools  have  some  credibility  established.  The  structure  permits  flexibil 
ity  in  adding  new  tools  to  the  architecture.  As  the  tool  kit  expands, 
the  user  will  be  able  to  analyze  a  wider  range  of  issues,  (e.g..  concept 
issues  such  as  mission  effectiveness ) .  and  a  larger  class  of  users, 
beyond  just  the  MPT  community,  may  benefit.  An  intelligent  interface 
among  the  tools  also  reduces  the  user's  training  burden. 

Specifying  HSI  system  and  task  data  is  the  primary  driver  in  pre¬ 
paring  for  many  analyses  in  TACHSI .  The  desired  level  of  task  decomposi 
tion,  the  source  of  data  (i.e..  access  to  predecessor  system),  or  the 
presence  of  expert  system  aids  will  significantly  alter  the  time  needed 
to  describe  the  nature  of  HSI  under  study.  Consistency  across  descrip¬ 
tions  is  necessary  to  ensure  TACHSI’s  effective  use  across  analysis 
models.  Simplifying  assumptions  may  be  necessary  in  the  prototype  imple 
mentation,  and  full  decomposition  and  aiding  capability  may  be  deferred 
until  operational  system  development  in  Phase  III.  Similarly,  the 
degree  of  task  network  sophistication  accommodated  in  the  prototype  may 
be  reduced  to  demonstrate  the  concept,  and  full  branching  capabilities 
may  be  deferred  as  well. 

TACHSI  will  include  capabilities  to  prepare  both  standard  and  ad 
hoc  analysis  reports.  Task  2  will  focus  on  the  standard  reports;  the  ad 
hoc  reports  will  be  deferred.  The  library  of  standard  reports  will 
evolve  as  tools  are  added  and  user  requests  expand.  Contents  of  stan¬ 
dard  reports  should  include  design/analysis  graphs  supporting  system  and 
MPT  tradeoff  studies,  high  driver  identification,  and  cost  assessment. 
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SAINT  simulation  output  will  be  stored  in  databases  for  subsequent 
analysis,  such  as  the  examples  presented  in  section  3.4. 

Reporting  and  charting  features  represent  the  primary  communication 
device  among  system  developers  throughout  the  acquisition  process.  The 
TIP  will  support  this  process  through  representative  charts  and  graphs. 

A  prototype  of  the  architecture  will  be  demonstrated  to  ASD  users 
at  the  completion  of  Task  2.  Comments  and  feedback,  especially  regard¬ 
ing  system  functions  and  user-oriented  interfaces,  will  be  critical  to 
ensuring  the  success  of  the  prototype  system. 

5.4  TASK  3:  DEVELOP  AND  TEST  TACHSI  INTERFACE  TO  HSI  TOOLS 

Whereas  Task  2  establishes  the  framework  for  the  overall  system. 
Task  3  takes  the  framework  and  makes  it  useful  by  integrating  the 
selected  HSI  performance  models  in  a  phased  approach.  The  basic  sub¬ 
tasks  applied  within  each  phase  are: 

(1)  Develop  a  demonstration  p.-ototype  to  demonstrate  functionality 
and  interfaces  for  each  phase; 

(2)  Test  and  evaluate  with  users:  and 

(3)  Integrate  operating  tools  within  TACHSI,  and  update  interfaces 
and  documentation  as  necessary. 

The  product  of  Task  2  is  the  final  prototype  TACHSI  system,  complete 
with  interfaces  to  functional  planning  tools.  The  specification  docu¬ 
ments  produced  in  Task  1  are  again  used  as  controls  to  the  process. 
Inputs  include  the  TACHSI  architecture  and  the  software  for  the  suite  of 
HSI  tools. 

As  mentioned  previously,  the  HSI  tool  suite  will  include  the  I DE F0 

methodology  for  top-down  process  decomposition,  the  SAINT  task  network 
simulation  model,  the  IDEAL  performance  database,  and  an  implementation 
of  the  Isoperformance  method  for  trading  off  training,  personnel  and 
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equipment.  Task  3  will  integrate  these  tools  in  the  following  sequence 
or  phases: 


Phase - Tool  interface  and  condition  (if  anvl 

1  Performance  database  for  selected  simulation  conditions 
with  limited  branching. 

2  IDEF0 . 

3  SAINT  simulation  and  output  analysis/reporting. 

4  Isoperformance  analysis. 

5  Expansion  to  performance  database  and  simulation 

interface  for  more  complex  activity  branching 
conditions . 

At  the  conclusion  of  each  phase,  the  prototype  system  will  be  demon¬ 
strated  and  delivered  to  users  at  ASD  for  their  use.  comments,  and  feed¬ 
back.  The  specific  functions  to  be  developed  and  tested  in  phase  5  will 
depend  on  the  results  of  the  prior  phases.  An  alternative  implementa¬ 
tion  in  phase  5  could  involve  other  types  of  KSI  analysis  or  reporting 
capability.  For  example,  this  could  include:  an  assessment  of  operator 
workload  based  on  the  SAINT  simulation  results  showing  resource  utiliza¬ 
tion  over  time  error  analysis  for  safety  assessment:  a  refined  linkage 
to  ISD  models  such  as  the  ISD/tSAR  Decision  support  system;  or  an 
identification  of  training  high  drivers. 

5.5  EVALUATE. AMD  DOCUMENT  TACHSI  AND  PHASE  III  PLAN 

The  primary  products  of  this  task  include  a  current  system  speci¬ 
fication  manual  and  end  user  documentation,  as  well  as  a  final  report 
which  includes  recommendations  for  Phase  III.  The  system  specification 
document,  which  includes  the  functional  and  database  specifications, 
will  be  updated  to  reflect  the  results  of  the  iterative  process  of 
design  and  development  followed  throughout  Tasks  2  and  3. 
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User  documentation  will  be  developed  and  will  include  the 
following: 

•  System  summary,  including  system  environment,  modes  of 
operation ; 

•  System  access,  including  first-time  use,  and  scenarios  of  use 
in  design:  and 

•  Processing  reference  guide,  including  error  recovery  and 

messages. 

A  final  user  and  sponsor  review  of  the  prototype  system  will  be  con¬ 
ducted  at  the  conclusion  of  the  Phase  II  effort. 

The  Phase  III  recommendations  will  present  directions  for  the 
operational  system  development,  and  will  highlight  those  areas  missing 
from  the  prototype  system.  Included  in  this  latter  group  are 

•  Design  audit  trail  and  version  control; 

•  Multi-user,  network  operations; 

•  Interfaces  to  product  design/CAD/CAE  systems,  and  operator 
graphic  representations;  and 

•  Issues  for  software  migration  to  the  operational  system. 

The  final  report  and  Phase  III  recommendations  will  also  outline  a 
plan  for  commercialization. 

5.6  .RESOURCES 

Estimated  Phase  II  project  personnel  staffing  resources  include 
four  people  with  a  mix  of  skills.  These  include: 

•  Project  Leader/Principal  Investigator  (part  time); 

•  Junior  Human  Factors  Engineer  (part  time); 

•  Database  analyst  (part  time);  and 

•  Software  engineer  (full  time). 

Overall  project  duration  for  implementing  the  prototype  system  is 
18  months. 
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This  Requirements  Analysis  Document  leads  the  way  for  developing  a 
planning  tool  for  analyzing  human  system  integration  designs  in  the  con¬ 
cept  phase  of  system  acquisition.  The  automated  TACHSI  tool  will  be  a 
portable  desktop  decision  aid.  It  has  potential  application  by  elements 
in  Air  Force  program  offices  and  organizations,  and  complements  efforts 
in  the  private  sector  by  those  who  are  involved  with  the  conceptual 
design  of  complex  human-operated  systems. 
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